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Introduction 


This is the first of four papers that make up 
a protocol recommendation for AX.25 at Level 3A, 
the Network Sublayer. 

This series of papers is being generated by 
AMRAD after a series of meetings between AMRAD 
members Paul Sune W4RI, Terry Fox, WB4JFI, 
Dave Borden, K8MMO, Eric Scace, K3NA, and Gordon 
Beattie, N2DSY. 


These papers are first drafts, and are being 
released to the amateur community for comments and 
suggestions. Anyone wishing to comment is invited 
to write to the author at the above address, or 
irae to the AMRAD Newsletter at the following 
address: 


Amateur Radio Research and Development Corp. 
PO Drawer 6148 
McLean, VA 22186-6148 


The protocol recommendation that follows is 
based on the CCITT X.25 Level 3 specification. 
Since many amateurs pt eee not have the CCITT 
ook uiSnee available to them, it was decided to 

fa pea the entire document; with additions or 
eletions necessary to apply the protocol to the 
amateur enviroment. 


This paper will discuss some of the basics of 
the Network Sublayer, along with operating 
procedures. The next paper will describe the 
actual packet formats. The third in the series 
will describe optional user requested facilities, 
and the fourth paper will include the Annexes 
mentioned throughout the previous three papers. 


AX.25 Network Sublayer Recommendation 


Network Sublayer Basics 


The Network Layer of the ISO Reference Model 
is generally broken into two different parts, each 
responsible for separate, distinct functions. 
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3.0.1 


The Network Sublayer is responsible for the 
proper operation of a local, or metropolitan 
group of interconnected packet deviices.. These 
interconnected devices make up a network of packet 
users, who wish to communicate either with each 
other, or possibly with others outside of the 
metropolitan network. How the data is transferred 
outside of the metropolitan network is a function 
of the Internetwork Sublayer, and as such, falls 
outside the domain of this recommendation. 


The Network Sublayer relies on a lower level 
protocol (usually the AX.25 Link Heyer eels 
to cause data at the Network Layer be 
transferred from one device to another. hile the 
Link Layer protocol is responsible for the user 
data to transverse a physical medium properly, the 
Network Sublayer is responsible for the accurate 
transfer of data through the metropolitan network. 
This is usually acco ae by having, individual 
devices interconnected to a master device (called 
a network controller, network hub, packet switch, 
or DCE). Any packet user wishing to communicate 
with another user (either within the metropolitan 
network, or outside it) does this through this 
master device. 


Subject for further Shuey. is how two stations 
communicate at the Network Sublayer in the absence 
of a packet switch. One proposal is to have the 
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3.0.52 


AMRAD 


two stations arbitrate which one will become the 
packet switch by a simple comparison of callsigns. 
3.0.4 Network Sublayer Responsibilities 

The Network Sublayer is responsible for 
taking data from the 'higher level protocols and 
sending that data to the intended destination 
device, eee the lower level protocols that may 
be implemente 


Since the recommended protocol is connection 
oriented, in order to pass data over the network, 
a “virtua connection must first be made with the 
destination device through a network controller 
or packet switch. This recommendation handles the 
establishment, proper operation, recovery from 
errors, and tearing down of these connections 
necessary to pass data, along with the actual data 
transmissions. 


This protocol is also responsible for passing 
along certain status information of the network 
or lower levels to the higher level protocols. 
3.0.5 Device Descriptions 
At the Network Sublayer there are two types 
of devices presently defined. Their descriptions 
have been adjusted slightly to take into account 
the amateur enviroment. Neither one of these 
devices are usually "real" devices, rather they 
are usually a software implemented "machine". 


3.0.5.1 


At the Network pubieves: the Data Terminating 

Equipment device, hereafter called the DTE, is 

Berit an considered the individual packet Nees i 
e it an actual user, a remote network ciel Lie 

a large computer device running programs availab 

to other users. 


Data Circuit-Terminating Equipment 


At the Network Sublayer, the Data Circuit- 
Terminating Equipment : queens device, hereafter 
called the DCE is either the packett switch 


Data Terminating Equipment 


By 


device or if there is no packet switch device 
availzhla, one of the DTE devices wishing to 
communicate. The arbitration of the second 


possibility is undefined at this point, and is a 


subject for further study. 
3.0.6 


Units of Data Transferred at the 
Network Sublayer 


The basic unit of data that is transferred 
across a DTE/DCE interface is called a "pactait". 
This packet is contained within the information 
field of Link Layer frames. All packets must 
contain an integral number of octets. In 
addition, the data field of data packets must also 
contain an integral number of packets. 


3.0.7 Types of cannections available 


Amateur X.25 defines only one type of 
connection at the metropolitan network level, that 
of the virtual call. Permanent virtual circuits 
and datagrams are not supported by by AX.25 as 
presently defined. 


3.1 Logical Channels 


To enable multiple simultaneous virtual 


calls to exist, logical channels are used. Each 
virtual call. is assigned a logical channel oa 
number (LCGN) (less than or equal to 15 decimal 


and a logical channel number (LCN) (less than or 
equal to 255 decimal). A logical channel group 
number and a_ logical channel number is assigned 
during the call set-up phase. The actual range of 
logical channel cunbers available is established 
by the network, and agreed upon at the time of 
connection to the network. Annex A shows the 
recommendation of LCGN and LCN values used. 


3.2 Basic Structure of Packets 


Every packet transferred across the DTE/DCE 
interface consists of at least three octets. 
Within these three octets are a general format 
identifier, a logical channel identifier, and a 
packet type identifier. Additional packet fields 
may be appended as CP Prepniaes: Packet types are 
shown in Table 5/AX.25, 


From DCE to DTE From DTE to DCE i 
| Call set-up and c ' 
! Incoming call 
! Call connected 
! Clear indication 


ee 

! Call request 
Call accepted 
Clear request 


! DCE clear DTE clear 

| confirmation confirmation 

! Data and interrupt 

! DCE data ! DTE data 

! DCE interrupt ! DTE interrupt 

! DCE interrupt | DTE interrupt 
: confirmation confirmation 

! Flow control and reset 

! DCE RR ! DTE RR 

! DCE RNR ! DTE RNR 

! Reset indication ! Reset request : 
! DCE reset confirmation DTE reset confirmation! 
| Restart 

! Restart indication ! Restart request 
! DCE restart ! DTE restart 
' confirmation | confirmation 

! Diagnostic 

! Diagnostic 


Table 5/AK.25 AX.25 Packet types 


.3 Procedure for Restart 


The restart procedure is used to initialize 
or re-initialize the network level DTE/DCE 
interface. The restart procedure clears all 


virtual calls at the DTE/DCE interface. 
Batol Restart by the DTE 


The DTE may at any time request a restart by 
sending a restart request packet across the packet 
inter face. This will then place each ae 
channel in the DTE restart request state (r2). 


The other device (DCE or acres another 
DTE) will confirm the restart by sending a DCE 
restart confirmation packet and placing the 
logical channels, used between the two devices in 
the ready state (pl). 


The DCE restart confirmation packet only 
applies to virtual calls between the requesting 
DTE and the receiving DCE. This restart has no 
affect on virtual calls with any other device 
Time spent in the DTE_ restart request state (2) 
shall not exceed time-limit T20 (see Annex D). 


36862 Restart by the DCE 


The DCE may initiate a restart of the packet 
interface by sending a restart indication packet. 
All virtual calls for the, specified packet 
interface are then placed in the DCE restart 
indication state (r3), While in this state the 
DCE will ignore all packets received from the DTE 
involved except for restart request and DTE 


restart confirmation packets. 


The DTE will confirm the restart by sending a 
DTE restart confirmation packet, and then place 


all virtual calls between sb) and the DCE in 
question in the ready state (pl). 
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The action taken by the DCE when the DTE does 
not_ confirm restart within time-out T10 is given 
in Annex D. 


3533 Restart Collision 


Restart collision occurs when both the DCE 
and DTE simultaneously send a restart request and 
a restart indication packet. When this happens, 
the DCE will consider the restart completed. The 
DCE will not expect a DTE restart confirmation 
packet and will not send a DCE_ restart 
confirmation packet. This places all virtual 
calls between the affected DTE/DCE interface in 
the ready state (pl). 


3.4 Error Handling 


Table C-1/AX.25 indicates the reaction of the 
DCE when certain error conditions are encountered. 
Error conditions other than those specified in the 
table are discussed in sections 4 and 5 


3.4.1 Diagnostic Packet 


The diagnostic packet may be used to indicate 
error conditions when the usual methods (ex. 
reset, clear and restart with cause and 
diagnostic) are inappropriate. A_ diagnostic 

acket from a DCE should provide information on 
he error situations that are considered 
unrecoverable at the packet layer. This 
information permits analysis of the error, and 
recovery by higher levels at the DTE, if possible. 


A diagnostic packet is issued only once per 
particular instance of an error condition. A DTE 
receiving a diagnostic packet is not required to 
confirm reception. After a DCE sends a diagnostic 

acket, it will same in the same state for that 
jogical channel(s) as it was when the diagnostic 
was generated. 


3.5 Effects of the Physical and Link Layer an the 
“~~ Packet Level 


Changes of operational states of the Physical 
and Link Layers do not implicity alter the state 
of each logical channel at the packet level. When 
changes that affect the packet level do occur 
they are explicitly indicated at the packet leve 
ot the use of restart., clear, or reset procedures, 
whichever is appropriate. 


A failure at the Physical and/or Link Layers 
is defined to be when the DCE cannot transmit or 
receive any frames because of abnormal conditions 
at the Physical and/or Link Layer. 


When a failure on the Physical and/or Link 
Layer is detected, virtual calls will be cleared, 
and further action may be taken as described in 
section 4.6. 


When the failure of the ae fae and/or Link 
Layer is recovered, the DCE will send a restart 
indication packet with the cause "Network 
operational" to the DTE. Any further action to be 
taken is defined in section 4.6. 


In other out-of-order conditions on the 
Physical and/or Link Layer, the DCE will clear all 
virtual calls using the affected link. 


Note: An out-of-order condition on the Link 
Level includes reception of a disc command or a 
transmission of a disc command by the DCE, in the 
case of a single link procedure. 


4 Procedures for virtual circuit services 


4.1 Procedures for virtual call service 


Figures B-1/AX.25, B-2/AX.25, and B-3/AX.25 
in Annex B show the state diagrams which give a 
definition of events at the packet level DTE/DCE 
interface for each logical channel used for 
virtual calls. 


Annex C gives details of the action taken by 
the DCE on reception of packets in each state 
shown in Annex B. 


The call Py? and clearing procedures 
described in the following paragraphs apply 
independently to each logical channel assigned to 
the virtual call service at the DTE/DCE interface. 
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4.1.1 Beddya te 


If there is no call in existance, a logical 
channel is in the ready state (pl). 


4.1.2 Call request packet 


The calling DTE shall indicate a call request 
by sending a call request packet across the 
DTE/DCE interface, The logical channel selected 
by the DTE is then in the DTE waiting state (p2). 
The call request acket includes the called DTE 
address. The calling DTE address shall also be 
used. 


Note 1. A DTE address shall be encoded as 
described in Annex F of this 


document. 

Note 2. In order to minimize the risk of 
call collisions, the call request 
packet should use the logical 
channel with the highest number in 
the range allowed in Annex A that is 
in the ready state. 

4.1.3 Incoming call packet 


The DCE will indicate that there is an 
incoming call by ecnding across the DTE/DCE 
interface an incoming call acket. This will 
iis the logical channel in the DCE waiting state 
p3). 


The incoming call packet will use the logical 
channel in the ready state with the lowest number 
in the range allowed in Annex A. The incoming 
call packet shall include the DTE calling address 
and the called DTE address fields encoded as 
described in Annex F. 


4.1.4 Call accepted packets 


The called DTE shall indicate its acceptance 
of the call b sending a call accepted packet 
across the DTE/DCE interface. This call accepted 
packet will specify the same logical channel as 
that of the incoming call packet. This places the 
specified logical channe in the data transfer 
state (p4). 


If the called DTE does not accept the call by 
sending a call accepted packet or does not reject 
it by sending a clear request packet as described 
in paragraph 4.1.7 within time-out T1l (see Annex 
D), the DCE will consider it as a procedure error 
from the called DTE and will clear the virtual 
call aceordin to the procedure described in 
paragraph 4.1.8. 


451.5 Call connected packet 


The reception of a call connected packet by 
the calling DTE specifying the same logical 
channel as that arene in the call request 
acket indicates that the call has been accepted 
y the called DTE by means of a call accepted 
packet. This places the specified logical channel 
in the data transfer state (p4). 


The time spent in the DTE waiting state (p2) 
will not exceed time-out T21 (see Annex D). 


4.1.6 Call collision 


Call collision occurs when a DTE and DCE 
simultaneously send a call request packet and an 
incoming call packet specifying the same logical 
channel. The DCE will proceed with the call 
request and cancel the incoming call. 


4.1.7 Clearing by the DTE 


The DTE may indicate clearing at any time by 
ecog tts a clear request packet across the DTE/DCE 
inter fa (see paragraph 4.5). The logical 
channel is then in the DTE clear request state 
(p6). When the DCE is prepared to free the 
logical channel, it will send a clear confirmation 
packet across the DTE/DCE interface specifying the 
proper logical channel. This acts channel is 
then placed in the ready state (p ). 


The DCE clear confirmation packet has only 
local significance, it does not affect calls 
outside the one logical channel cleared (such as 
end-to-end calls). The time spent in the DTE 


clear request state (p6) will not exceed time 
limit T23 (see Annex D). 


It is possible that subsequent to sending a 
clear request packet and prior to the reception of 
a DCE clear confirmation packet, the DTE will 
receive other types of packets (depending of the 
state of the logical channel). 


The calling DTE may abort a call by clearing 
it before it has received a call connected or 
clear indication packet. 


The called DTE may refuse an incoming call by 
clearing it as described above instead of sending 
a call accepted packet. 


4.1.8 Clearing by the DCE 


The DCE will indicate clearing by 
transmitting across the DTE/DCE interface a clear 
indication packet (see 4.5). The logical channel 
is then in the DCE clear indication state (p7). 
The DTE shall respond by sending a DTE clear 
confirmation packet. The logical channel is then 
placed in the ready state (fl). 


The action taken by the DCE when the DTE does 
not confirm clearing within time-out T13 is given 
in Annex D. 


4.1.9 Clear collision 


Clear collision occurs when a DTE and DCE 
simultaneously send a clear request packet and a 
clear indication acket specifying the same 
logical channel number. When this happens, the 
DCE will consider the clearing completed and will 
not expect a DTE clear confirmation packet. The 
DCE will not send a DCE clear confirmation packet. 
The logical channel will be placed in the ready 
state (pl). 


4.1.10 


If a call cannot be established, the DCE will 
send a clear indication packet specifying the 
logical channel indicate in the call request 
packet to the calling DTE. 


Unsuccessful call 


4.1.11 Call progress signals 


The DCE will be capable of transferrirg to 
the DTE clearing progress signals as specified in 
a future document (AX.96). 


Clearing call progress signals will be 
carried in clear indication packets which will 
terminate the call to which the packet refers. 
The method of coding clear indication packets 
containing call progress signals is detailed in 
paragraph 6.2.3. 


4.1.12 Data transfer state 


The procedures for the control of packets 
between DTE and DCE while in the data transfer 
state are contained in section 4.3 below. 


4.3 Procedures for data and interrupt transfer 


The data transfer and interrupt procedures 
described in the following paragraphs apply 
independantly to each logical channel assigned for 
virtual calls existing at. the DTE/DCE interface. 


Normal network operation dictates that user 
data in data and interrupt packets are all passed 
transparently, unaltered through the network in 
the case of Rae <5 DTE to. packet DTE 
communications. he order of bits in data packets 
is preserved. Packet sequences are delivered as 
complete packet sequences. Diagnostic codes are 
treated as described in sections 6.2.3, 6.5.3, and 
6.6.1. 


Av3.1 States for data transfer 


A virtual call logical channel is in the data 
transfer state (p4) after completion of call 
establishment and prior to a clearing or restart 
procedure. Data, interrupt!, flow control, and 
reset packets may be transmitted and received by a 
DTE in the data transfer state of a logical 
channel at the DTE/DCE interface. In. this state, 
the flow control and reset procedures described in 
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section 


4.4 apply to data transmission on that 
logical channe 


to and from the DTE. 


; When a virtual call is cleared, data and 
lees 8S) packets may be discarded by the network 


(see 4, In addition, data, interrupt, flow 
control, and reset packets transmitted by a DTE 
will be ignored ‘py the DCE when the Logical 


channel is in the DCE clear indication state (p/). 
It is left to the DTE to define DTE to DTE 
protocols able to cope with various possible 
situations that may occur. 


4.3.2 


User data field length of data packets 


7 The standard maximum user data field length 
is 128 octets. 


The user data field of data packets 
transmitted by a DTE or DCE may contain any number 
of octets up to the agreed upon maximum. e user 
data field shall contain an integral number of 
octets. 


If the user data field in a data packet 
exceeds the maximum user data field length, the 
DCE will reset the virtual call with the resetting 
cause “Local procedure error”. 


4.3.3 


The setting of the Delivery Confirmation bit 
(D bit) is used to indicate whether or not the DTE 
wishes to receive an end-to-end acknowledgement of 
delivery of the packet with the D bit set. This 
acknowledgement is for data it has transmitted, 
and the acknowledgement is made using the packet 
receive sequence number P(R) (see 4.4 below 4 


Deliverv confirmation bit 


The use of the D bitdoes not obviate the 
need for a higher level protocol between 
communicating DTEs which may be used independantly 
of the D bit procedure to recover from user or 
network generated resets and clearings. 


4.3.4 More data mark 


If a DTE or DCE wishes to indicate a sequence 
of more than one packet, it uses the More Data 
Mark bit (M bit) as defined below. 


The M bit can be set tO one in any data 
packet. When it is set to one in a full data 
packet, or in a partially full data packet also 
carrying the D bit set to one, it indiactes that 
more data is to follow. Networks supportg AX.25 
will not perform data packet segmentation or 
recombination. 


A sequence of data packets with every M bit 
set to one except the last one will be delivered 
as a sequence of data packets with the M bit set 
to one except for the Iast one when the original 
packets having the M bit set to one are either 
ull (irrespective of the setting of the D bit) or 
partially full but have the D bit set to one. 

Two catgories of epeara i A and B have been 
defined as shown in Table 6/AX.25. Table 6/AX.25 
also illustrates the networks treatment of the M 
and D bits at both ends of a virtual call. 


{ Data packet sent !'! Data packet ! 


{ by source DTE '! rcevd by the ! 
! a destination DTE! 
{Category ! M ! OD YFull!! D ! 
' B !0orl !0 !No!! O ! Of 
| B 1 Oo !1 +j%!No!! 0O ! 1 $! 
! B ! 1 $1 ! Natl. 1 ! 1 1! 
| B ! 0 !0 ! Yes!! 0 o ! 

B ! 0 {1 ! Yes!! 0 1 3! 
! A ! 1 !0 ! Yes!! 1 0 ! 
| B ! 1 !1 ! Yes!! 1 ! 1 ! 


Table 6/AX.25 
Definition of two categories of data packets 
and network treatment of the M and D bits 


4.3.5 Complete packet sequence 


A complete packet sequence is defined as 
being composed of a rel Fad category B packet and 
all contiguous preceeding category A packets 
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having the exact maximum user data field length 
with the M bit set to one and the D bit set to 
zero. All other data packets are category B 
packets. 


When transmitted by a DTE source, a complete 
packet sequence is always delivered to the 
destination DTE as a single complete packet 
sequence. 


The user data field of the last packet of the 
sequence may have less than the maximum length and 
if M and bits are set as described in Table 


Since the maximum user data field length is 
the same at both ends, the user data fields of 
data packets are delivered to the receiving DTE 
exactly as they have been received by the network. 
If the last packet of a complete packet sequence 
transmitted by the source DTE has a data field 
less than the maximum length with the M bit set to 
one and the D bit set to zero, then the last 


packet of the corrplete packet sequence delivered 
to the receiving, DIE will have the M bit set to 
zero. 

4.3.6 Qualifier bit 


A complete packet sequence may be on one of 
two levels. If a DTE wishes to transmit on more 
than level, it uses the Qualifier bit (Q bit). 


When only one level of data is being sent on 
a logical chamnel, the Q bit is always set to 
zero. If two leveis of data are being sent, the 
transmitting DTE should set the Q bit in all data 
packets of a complete packet sequence to the same 
value, either zero or one. A complete packet 
sequence, which is sent with the Q bit set to the 
same value in all packets, is delivered by the 
network as a complete packet sequence with the Q 
bit set in all packets to the value assigned by 
the transmitting DTE. 


When the Q bit is not set to the same value 
by the transmitting DTE within a a eer packet 
sequence?) a network supporting AX.25 will reset 
the logical channel with the cause “Local 
procedure e " -and a diagnostic code of 
Inconsistant Q bit setting”. 


ives an example of the 
n the Q bitisset to 


0 


Recommendation AX.29 
procedures to be used w 
one. 


(see 
bit 


Packets are numbered consecutivel 
4.4.1.1) regardless of their data level 
setting). 


4.3.7 Interrupt procedure 

The interrupt procedure is used to allow a 
DTE to transmit data to the remote DTE without 
following the flow control procedure applying to 
data packets (see 4.4). The interrupt procedure 
applies only in the flow control ready state (dl) 
within the data transfer state (p4). 


The interrupt procedure will have no effect 
on the transfer and flow control procedures 
applying to the data packets on a virtual call 
logical channel. 

To transmit an interrupt, the DTE sends a DTE 
interrupt packet across the DTE/DCE interface. 
The DTE should not send a second DTE a ene 
packet until the first one is confirmed by the 
reception of a DCE pega t confirmation packet 
(see Note 2 to Table C-4/AX.25). After the 
interrupt procedure is completed at the remote 
end, the DCE will confirm the receipt of the 
interrupt by sending a DCE interrupt confirmation 
packet. The reception of a DCE interrupt 
confirmation packet indicates that the interrupt 
has been confirmed by the remote DTE by means of a 
DIE interrupt confirmation packet. 


The DCE indicates an interrupt from the 
remote DTE by sending a DCE interrupt packet 
across the DTE/DCE interface which contains the 
same data field as that in the DTE interrupt 
packet transmitted by the remote DTEE. DCE 


interrupt packet is delivered at or before the 
oint in the data packets stream at which the DTE 
nterrupt packet was generated. he DTE will 


confirm reception of the DCE interrupt packet by 
sending a DIE interrupt confirmation packet. 

4.4 Procedures for flow control 

Section 4.4 only applies to the data transfer 
state (p4) and epee i fies the procedures covering 
flow control Of data packets and reset on eac 
logical channel used for a virtual call. 

4.4.1 Elow Control 

The transmission of data packets across a 
DTE/DCE interface of a logical channel in a 
virtual call is controlled separately for each 
direction, and is based on authorization from the 
receiver. 


Flow control also allows a DTE to limit the 
rate at which it accepts packets across the 
DTE/DCE interface, noting that there is also a 
network-dependant fimit on the number of packets 
ey may be within the network for the virtual 
call. 


4.4.1.1 Numbering of data packets 
Each data acket transferred across the 
DTE/DCE inter face for each direction of 


transmission in a virtual call is numbered 
sequentially. 


The sequence numbering scheme of the packets 
is in module 8. The packet sequence numbers cycle 
through the entire range from zero to seven. The 
acket sequence numbering scheme is the same for 
Both directions of transmission and is common for 
all logical channels at the DTE/DCE interface. 


Only data packets contain this sequence 
number, which is called the packet send sequence 
number P(S). 


The first data 
interface for each 
when the logical channel has 
control rea state (dl), wil 
sequence number equal to zero. 


AAs Led 


For each direction of a data transmission 
over a virtual call logical channel, a window is 
defined as the ordered set of W consecutive packet 
send sequence numbers of the data packets 
authorized to cross the interface. 


acket sent across the DTE/DCE 
irection of data transmission 
ust entered the flow 

have a packet send 


Window description 


The lowest sequence number in the window is 
referred to as the lower edge. When a virtual 
call at the DTE/DCE interface has just entered the 
flow control ready state (dl), the window related 
to each direction of data transmission has a lower 
window edge equal to zero. 


The packet send sequence number of the first 
data packet not authorized to cross the interface 
is the value of the lower window edge plus W 
(module 8). 


The standard window size W is 2 for each 
direction of data transmission at the DTE/DCE 
interface. 


4.4.1.3 Flow control principles 


When the sequence number P(S) of the next 
packet to be sent by the DCE is within the window, 
the DCE is authorized to transmit this data packet 
to the DTE. When the sequence number P(S) of the 
next data packet to be transmitted by the DCE is 
outside of the window, the DCE shall not transmit 
a data packet to the DTE. The DTE should follow 
this same procedure. 


When the sequence number P(S) of the data 
packet received by the DCE is the next in sequence 
and is within the window, the DCE will accept the 
data packet. A received data packet containing a 
P(S) that is out of sequence (such as when there 
is a gap in the received P(S) numbering, or a 
duplicate P(S) number), out of window, or not 
equal to zero for the first data packet after 
entering the flow control ready state (dl) is 
considered by the DCE as a local procedure error. 
The DCE will reset the virtual call (see 4.4.3) 
The DTE should follow the same procedure. 
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A number (modulo S), referred to as a packet 
receive sequence number P(R), conveys across the 
DTE/DCE interface information from the receiver 
for the transmission of data packets. When 
transmitted across the DTE/DCE interface, a P(R) 
becomes the lower window edge. In this way, 
additional data packets may be authorized by the 
receiver to cross the DTE/DCE interface. 


The packet receive sequence number, P(R), is 
conveyed in data, receive ready (RR), and receive 
not ready (RNR) packets. 


The value of a P(R) received by the DCE must 
be within the range from the last PCR) received by 
the DCE up to and including the packet send 
sequence number of the next data packet to be 
transmitted by the DCE. Otherwise, the DCE will 
consider the reception of this P(R) as_a procedure 
error and will reset the virtual call. The DIE 
should follow the same procedure. 


The receive sequence number P(R) is less than 
or equal to the next data packet sequence number 
expected, and implies that the DTE or DCE 
transmitting P(R) has accepted at least all data 
packets numbered up to and including P(R)-1. 


4.4.1.4 


When the D bit is set to zero in a data 
packet having P(S) equal to p, the significance of 
the returned P(R) corresponding to the data packet 
(ex. P(R)=ptl) is a_ local updating of the window 
across the packet level interface so that the 
achievable throughput is not constrained by the 
DTE-to-DTE round trip delay across the network(s). 


Delivery confirmation 


When the D bit is set to one in a data packet 
having P(S)=p, the significance of the returned 
P(R) corresponding to that data packet (ex. 
P(R)=ptl) is an indication that a P(R) has been 
received from the remote DTE for all data bits in 
the data packet in which the D bit had originally 
been set to one. 


When a DTE receives a data packet with the D 
bit set to one, it should transmit the 
corresponding P(R) as soon as possible in order to 
avoid the possibility of deadlocks (without 
waiting for further data packets). A data, RR, or 
RNR packet may be used to convey the pir) (see 
Note to 4.4.1.6). Likewise, the DCE is required 
to send P(R) to the DTE as soon as possible after 
it is received from the remote DTE. 


In the case where a P(R) for a data packet 
with the D bit set to one is outstanding, the 
local updating of the window will be deferred for 
subsequent data packets with the D bit set to 
zero. 


4.4.1.5 DTE and_DCE_ receive ready (RR) packets 


RR packets are used by the DTE or DCE to 
indicate that it is ready to receive W data 


packets within the window starting with P(R), 

where P(R) is indicated in the RR pac:kt. 

4.4.1.6 DTE and DCE receive not ready (RNR) 
pack-— 


RNR packets are used by the DTE or DCE to 
indicate a temporary inability to accept 
additional data packets for a given virtual cal... 
A DTE or DCE receiving an RNR packet shall sto 
transmitting data packets on the indicated logica 
channel, but the window is updated by the P(R) 
value of the RNR packet. The receive not ready 
condition is cleared by the transmission in the 
same direction of a RR packet or by a reset 
procedure being initiated. 


The transmission of a RR packet after a RNR 
packet at the packet level is not to be taken as a 
demand for retransmission of packets which have 
already been transmitted. 


The RNR packet may be used to convey across 
the DTE/DCE interface the P(R) value corresponding 
to a data packet which had the D bit set to one in 
the case that additional data packets cannot be 
accepted. 


ut characteristics 


The attainable throughput on virtual calls 

carried at the DTE/DCE interface may vary due to 
the stastical sharing of transmission and switch 
resources and is constrained by: 
1) the access line characteristics, local window 
size and traffic characteristics of other 
logical channels at the local DTE/DCE 
interface; 


2) the access line characteristics, local window 
size and traffic characteristics of other 
logical channels at the remote DTE/DCE 
interface, and; 

3) the throughput achievable on the virtual 
call through the network(s) independant of 
interface characteristics including number of 
active logical channels. This throughput may 
be dependant on network service 
characteristics such as window rotation 
mechanisms and/or optional user facilities 
requested on national,international calls. 


The attainable also be 
affected by: 


1) 
2) 


throughput — will 


the receiving DTE flow controlling the DCE; 


data packets 


the transmitting DTE not sencsos. 
sd length; 


which have the maximum data fie 
3) the local DTE/DCE window and/or packet sizes, 
and 3 


4) the use of the D bit. 


A ace aia class for one direction of 
transmission is an inherent characteristic of the 
virtual call related to the amount of resources 
allocated to this virtual call. This 
characteristic is meaningful when the D bit is set 
to zero in data packets. It is a measure of the 
throughput that is not normally exceeded on the 
virtual call. However, due to the statistical 
sharing of transmission and switching resources, 
it is not guaranteed that the throughput class can 
be reached 100% of the time. 


Depending on the network and the applicable 
conditions at the considered moment, the effective 
throughput may exceed the throughput class. 


The definition of ae ee class as a grade 
of service parameter is for further study. The 
grade of service might be specified when the D bit 
is set to zero or over a time period between the 
completion and initiation of successive D bit 
procedures. 


The throughput class can only be reached if 
the following conditions are met: 


a) the access data links of both ends of a 
virtual call are engineered for the 
throughput class; 

b) the receiving DTE is not’ flow 
controlling the DCE such that the 
throughput class is not attainable; 

c) the transmitting DTE is sending data 
ackets which have the maximum data 
ield length, and; 

d) all data packets transmitted on the 


virtual call have the D bit set to zero. 


The throughput class is pape ec in bits per 
second. At the DTE/DCE interface, the maximum 
data field we is specified for a virtual call, 
and thus the throughput class can be interpreted 
by the DTE as the number of full data packets per 
sie that the DTE does not have a need to 
exceed. 


The default throughput classes for both 
directions of transmission correspond to the user 
class of service of the DIE (see 7.4.2.6) but do 
not exceed the maximum throughput class supported 
by the network. 


The summation of throughput classes of all 
virtual calls supported at a DTE/DCE interface may 
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be greater than the data transmission rate of the 
access line. 


4.4.3 


The reset procedure is used to re-initialize 
the virtual call, and in so doing removes in each 
direction all data and interrupt packets which ma 
be in the network (see 4.5). When a virtual cart 
at the DTE/DCE interface has ©} ust been reset, the 
window related to_ each irection of data 
transmission has a lower window edge equal to 
zero, and the numbering of subsequent data packets 
to cross the DTE/DCE interface for each direction 
of data transmission shall start from zero. 


Procedure for reset 


The reset procedure can only apply in the 
data transfer state (p4) of the DTE/DCE interface. 
In any other state, th reset procedure is 
abandoned. As an example. when a clearing or 
restarting procedure is initiated, reset requested 
and reset indication packets can be left 
unconfirmed. 


For flow control, there are three states (dl, 
d2, and d3) within the data transfer state (p4). 
They are flow control ready (dl), DTE reset 
request (d2), and DCE reset indication (d3) as 
shown in the state diagram in Figure B-3/AX.25. 
When entering state p4, the logical channel is 
placed in state dl. Table Boa gax 25 specifies 
actions taken by the DCE on the reception of 
packets from the DTE. 


4.4.3.1 Reset request packet 


The DTE shall indicate a request for reset by 
transmitting a reset request packet specifying the 
logical channel. This places the logical channel 
in the DTE reset request state (d2). 


4.4.3.2 


The DCE shall indicate a reset Bead ine to the 
DTE a reset indication packet specifying the 
logical channel and the reason for the resetting. 
This places the logical channel in the DCE reset 
indication state (d3). In this state, the DCE 
will ignore all data, interrupt, RR, and RNR 
packets. 


Reset indication packet 


4.4.3.3 


Reset collision occurs when a DTE and a DCE 
simultaneously transmit a reset request packet and 
a reset indication packet specifying the same 
logical channel. Under these circumstances the 
DCE will consider the reset coumpleted. The DCE 
will not expect a DTE reset corfiirmation packet 
and will not transfer a DCE reset confirmation 
packet. This places the, logical channel in the 
flow control ready state (dl ). 


Reset Collision 


4.4.3.4 Reset confirmation packets 

When the logical channel is in the DTE reset 
request state (d2?), the DCE will confirm reset by 
sending to the DTE a DCE reset confirmation 
pee This places the pepteal channel in the 

low control ready state (dl ). 

The reset confirmation packet has only local 
significance. The time spent in the DTE reset 
request state (d2) will not exceed time limit T22 
(see Annex D). 


When the logical cahnnel is in the DCE reset 
indication state (d3), the DTE will confirm reset 
by transmitting to the DCE a DTE_ reset 
confirmation packet. This places the logical 
channel in the flow control ready state (d1). The 
action taken by the DCE when the DTE does not 
confirm the reset within time-out T1l2 is given in 
Annex D. 


4.5 Effects of clear, reset and restart 
procedures on the transfer of packets 

All data and interrupt packets generated by a 

DTE (or the network) before initiation by the DIE 


or the DCE of a clear, reset, or restart procedure 
at the logical interface will either be delivered 
to the remote DTE before the DCE transmits the 
corresponding indication on the remote interface, 
or be discarded by the network. 


No data or ca cgerke ee packets generated b 
DTE (or the network) er the cornpletion o 2 
reset procedure at the local interface will be 
delivered to the remote DTE before the completion 
of the corresponding reset procedure at the remote 
interface. 


When a DTE initiates a clear, reset, or 
restart procedure on its local interface, all data 
and interrupt packets which were generated by the 
remote DTE (or the network) before the 
corresponding indication is transmitted to the 
remote DTE will be either delivered to the 
initiatin DTE before DCE confirmation of the 
initial clear, reset, or restart request, or be 
discarded by the network. 


The maximum number OE pects which may be 
discarded is a function of network end-to-end 
delay and throughput characteristics and, in 
general, has no relation to the local window size. 

For virtual calls on which all data packets are 
transferred with the D bit set to one, the maximum 
number of packets which may be discarded in one 


direction of transmission is not larger than the 
window size of the direction of transmission. 


When a failure on the physical and/or link 
level is detected, the DCE will transmit to the 
remote end a clear with the cause "Out of order" 
for each existing virtual call. 


During the failure, the DCE will clear any 
incoming virtual calls with the cause "Out of 
order" and a diagnostic code of "Call setup or 
clearing problem". 


When the failure is recovered on the physical 
and link levels, the restart procedure will ‘be 
auctioned (see 3.5). 


5 Datagram service 


At this time, datagram service is not 
available in AX.25. 
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